Session Initiation Protocol (SIP) is an open signaling protocol for establishing many kinds of real-time communication sessions. Examples of the types of communication sessions that may be established using SIP include voice, video, and/or instant messaging. These communication sessions may be carried out on any type of communication device such as a personal computer, laptop computer, Personal Digital Assistant (PDA), or the like. One key feature of SIP is its ability to use an end-user's Address of Record (AOR) as a single unifying public address for all communications. Thus, in a world of SIP-enhanced communications, a user's AOR becomes their single address that links the user to all of the communication devices associated with the user. Using this AOR, a caller can reach any one of the user's communication devices, also referred to as User Agents (UAs) without having to know each of the unique device addresses or phone numbers.
The concept of an Application Router has been introduced with the Java Specification Request (JSR) 289 specification, the entire contents of which are hereby incorporated herein by reference. An Application Router is responsible for application composition. Within this context, application composition is the process of “chaining” multiple applications together into a logical sequence. When multiple applications are chained together, an application will process a given SIP message and once it is done with the needed processing, the application passes the SIP message to the next application in the chain.
Examples of SIP applications which may be included in an application composition include a presence application, a contact resolution application, a call setup application, a blacklist application, a voicemail application, and any other application which provides some sort of feature within the SIP architecture. As one example of an application composition, an incoming SIP message may first be filtered by a blacklist application before being passed to a normal call setup application, and then may be passed to a voicemail application after N rings.
JSR 289 states that it is the role of the developer to define the application composition by providing an Application Router implementation. An application in this sense refers to a single SIP Archive (SAR) or SAR file, where the SAR file contains one or more servlets. However, in reality, an application often comprises several SAR files and several servlets (this is then known as a multi-SAR application). Each SAR file represents a wrapper of some feature of the application. The developers often include a specialized Application Router implementation that is only capable of coordinating its own SAR files. Servlets may also be contained in a Web Archive (WAR) or WAR file.
JSR 289 does not define how a SIP Servlet Container should manage multiple Application Routers and, therefore, there is currently no mechanism for reliably deploying more than one multi-SAR application on the same SIP Servlet Container. This means that the application server is only able to deploy extremely limited applications, which is inefficient and counter to the main reason for using a SIP application server. As can be appreciated by one skilled in the art, this is highly inconvenient and a waste of resources since the server often has enough processing and/or memory resources to support more than one multi-SAR Application. In fact, it is analogous to using a web server such as WAS or Weblogic to only serve one set of pages or applications, instead of being able to host many websites and services simultaneously.
Consider, for example, two complex applications, each consisting of multiple SARs, which are deployed to a SIP Application Server. A first application might be a PBX type application, and a second application might be a call routing application. Due to the complexities of the call routing application it is necessary to write a custom application router for each application. These logical applications and associated application routers were developed separately but now there is a desire to host them on the same Application Server. The prior art solution to this problem is constrained to only being able to deploy a single custom application router. It will, therefore, be necessary to rewrite/merge the two application routers into a single application router. Such a process is time consuming and difficult.
Such an architecture is depicted in FIG. 1, where a communication system 100 includes a number of communication devices 108 connected to an application server 112 via a communication network 104. As can be seen in FIG. 1, the application server 112 may comprise a network interface 116 that allows the application server 112 to receive incoming SIP messages from the communication network 104.
Messages received at the network interface 116 are passed to a SIP Servlet Container 120. The SIP Servlet Container 120 is responsible for handling initial message requests and passing such requests to the application router 124. The SIP Servlet Container 120 may also act as a Back-to-Back User Agent (B2BUA) or proxy. Once the message is passed to the application router 124, the application router 124 examines the SIP request and selects which application (i.e., SAR file 128a-N) needs to be executed to complete request processing. It should be noted that the application router generally does not modify any requests. Accordingly, the application router 124 identifies the appropriate SAR file 128, and informs the SIP Servlet Container 120 of its decision. The SIP Servlet Container 120 then invokes the appropriate servlet within the SAR (determined by mechanism described in JSR 289) and the request is processed in accordance with that servlet. Once a request has been adequately processed, the SIP Servlet Container 120 transfers the request back to the network interface 116 where it can be transferred to another device in the communication network 100 for further processing. This may include passing the request to another application server or passing the request to a user communication device 108.
There are two common approaches to co-host multiple applications in accordance with JSR 289. The first is to simply run multiple instances of the application server 112, where each server will host a single multi-SAR application. This may include virtualization technology to partition a single physical machine. The second approach is for the deployer to implement a custom application router to coordinate these applications on the same server.
While present commercial practice normally deploys multiple server instances to host individual multi-SAR applications as described above, the one application per server approach can impose additional hardware and administration costs. The second approach requires the deployer to understand and re-implement routing logic for each application that is to be hosted. This process is prone to errors and increases the development/deployment time. In addition, the complexity of the machine increases with the number of applications residing thereon.